Repository navigation
chore(deps): lock Go 1.27.4 for release builds (GO-2026-6859) - #176
Conversation
Superseded — see the current review report for commit
|
Superseded — see the current review report for commit
|
![github-actions[bot]](https://avatars.githubusercontent.com/in/15368?s=60&v=4){kind=small}
Go 1.27.4 fixes GO-2026-6859, an HTTP/1 MaxBytesReader header race in net/http. govulncheck reports it as reachable from c1i, which is the only caller that sets go_vulnerability_scan; its release preflight fails and no release can publish while the locked toolchain is 1.27.3. Bump the four tool-lock entries to go1.27.4 (SHA256s from https://go.dev/dl/?mode=json) and the module's go directive. Update the lock table and the locked-Go gate fixtures: the newer-than-locked case now uses 1.27.5, and the single-version sanity fixture mutates 1.27.4 to 1.27.5. The ca-trust-guard x509 incident notes keep their 1.27.3 wording (they describe behaviour, not the lock). References: - https://pkg.go.dev/vuln/GO-2026-6859 Co-authored-by: c1-squire-dev[bot] <c1-squire-dev[bot]@users.noreply.github.com>
9a633d6 to
36a6301
Compare
Superseded — see the current review report for commit
|
General PR Review: chore(deps): lock Go 1.27.4 for release builds (GO-2026-6859)Blocking Issues: 0 | Suggestions: 0 | Threads Resolved: 0 Review SummaryThis PR moves all four locked Go toolchain entries in The test fixtures shift consistently:
The remaining
Coverage gap: this sandbox has no network access, so I could not check the new SHA256 values against Security IssuesNone found. Correctness IssuesNone found. SuggestionsNone. Resolved prior findings
Reviewed commit: |
Problem
Release preflight fails on c1i (and any caller with
go_vulnerability_scan: true) because the locked Go toolchain is 1.27.3, which has GO-2026-6859 (HTTP/1 server crash from aMaxBytesReaderheader race innet/http):c1i is the only caller that opts into
go_vulnerability_scan; it cannot override the locked toolchain (GOTOOLCHAIN: local), and itsverify-locked-go.shrejects a caller newer than the lock. So the fix belongs here: move the locked Go to 1.27.4.Change
.github/actions/locked-tools/tool-locks.txt: the four Go entries (linux/amd64,linux/arm64,darwin/arm64,windows/amd64) move togo1.27.4, with SHA256s from https://go.dev/dl/?mode=json.go.mod:go 1.27.3→go 1.27.4.docs/release-workflow.md: the lock table follows.scripts/test-tool-integrity.py: the newer-than-locked gate fixture uses 1.27.5 (1.27.4 is now equal, not newer), the allowed-directive loop includes 1.27.4, and the single-version sanity fixture mutates 1.27.4 → 1.27.5..github/actions/ca-trust-guard/README.md: the module-directive mention follows; the Go 1.27.3crypto/x509incident notes are unchanged (they describe behaviour, not the lock).Verification
go test ./...under Go 1.27.4: pass.python3 scripts/test-tool-integrity.py: 28 tests, OK (1 skipped).https://go.dev/dl/?mode=jsonforgo1.27.4.Release note
Merging this alone does not change what
@v4resolves to; callers pinned to@v4need a newv4.xrelease cut from this commit. Until then, c1i's release stays blocked (its preflight correctly refuses a Go 1.27.3 build).Related
#175 also touches
locked-tools; this change only rewrites the Go lock entries and the gate fixtures, so it should merge independently. Upstream: c1i#202 bumps c1i's owngodirective to 1.27.4 for CI.